[ES|QL] Lookup join and Inline stats support for query approximation (take 2)#146213
[ES|QL] Lookup join and Inline stats support for query approximation (take 2)#146213jan-elastic wants to merge 11 commits intoelastic:mainfrom
Conversation
jan-elastic
force-pushed
the
esql-approximate-with-join-2
branch
from
7b01baf to
a253b45
Compare
jan-elastic
force-pushed
the
esql-approximate-with-join-2
branch
from
a253b45 to
cc26793
Compare
alex-spies
left a comment
alex-spies
left a comment
There was a problem hiding this comment.
Hey, thanks @jan-elastic ! I appreciate the effort.
Having a more special class for lookup joins is how we started. We chose to depart from it to make logical plans less aware of physical execution. The fact that we're physically executing a lookup join is kinda a detail of the physical execution, so I'm not sure I'd want to go back on this decision to have a more specific LookupJoin.java after all.
It could make sense for the parsed plan to still have the info that we had a lookup join, but once we hit the optimizer we kinda want to be agnostic of that. (I realize that's not fully reflecting reality, as there's currently just 1 way to execute a lookup join.)
Maybe let's leave things as they are for now? Let me know if this would greatly simplify your work, of course, in which case I'm happy to consider this.
|
This was just a quick attempt at disambiguating It seems a bit confusing that the query contains a lookup join, in the logical plan it's rewritten to a generic join, and in the physical plan it becomes a lookup join again... 🤷 Anyway, I'll close this. |
3 participants
No description provided.